-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce render context #1766
Introduce render context #1766
Conversation
I will have to get this a bit cleaner, instead of passing around the render target it should now pass the render context which holds an active render target, that will eliminate all the temporary getRenderContext calls. |
a75eef4
to
226e88c
Compare
226e88c
to
63445f6
Compare
b6ae09c
to
9fe4f64
Compare
9fe4f64
to
f37a284
Compare
Unfortunately I can't refactor the RenderTarget argument just yet, there are some external functions that are missing and there might be shared use of the global render target instance. This has to do as a first pass until the rest is solved. |
} | ||
} // Impl | ||
|
||
void SoftwareDrawingContext::clear(Gfx::RenderTarget& rt, uint32_t fill) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is the reasoning behind this indirection? Why not just implement clear
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because at the moment everything passes RenderTarget but the context does not have its own state currently, I tried to do that but ran into a road block, the plan is to do eliminate that once we can do that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All seems sensible
@AaronVanGeffen are you want a check as well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than the commented-out header code that was pointed out, I have no objections 👍
The internal progress bars weren't displaying at all due to recent changes in the graphics stack (OpenLoco#1766). The progress bars use Gfx::renderAndUpdate to refresh the screen, but after this refactor, only SoftwareDrawingEngine::render was being called, but the SoftwareDrawingEngine::present it introduced was not. This left the screen not updated.
Closes #1762